home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / transcript_1003 / text0027.txt < prev    next >
Encoding:
Text File  |  1995-10-04  |  3.3 KB  |  72 lines
  1. > >Doing the actual texture mapping should be easy, but figuring out were to
  2. > >start in the texture, horizontally and vertically will be worse.
  3. > Well, as far as I can remember, there are some data which tell you if the
  4. > texture should be aligned on the top or the bottom of the wall pane. As for
  5.  
  6. Yes there is something like that.
  7.  
  8. > the horizontal position, I think it should depend on the actual position on
  9. > the map, line or column, depending on which one has the largest slope for
  10. > this wall, to give seamless walls. I'm almost sure doom does it this way.
  11.  
  12. The problem is that the top or left part of a wall may be covered by another
  13. wall closer to the screen. When that happens, the distance 'into' the wall
  14. segment has to be calculated. I believe that will mostly be taken care of
  15. automatically by the table based clipping routines, however, if a simple
  16. fixed point accumulator is added.
  17.  
  18. > >The last changes I made to DVIEW (did I send that version to anyone?) was to
  19. > I think I have this one. Do you put version numbers?
  20.  
  21. Below it doesn't seem like you have the version with the map drawing. Do you?
  22. Unfortunately there are no version numbers so far. That'll be one of the next
  23. things to add as well.
  24.  
  25. > >large. Disallowing crossing of walls has to be done in another way, but I've
  26. > >not yet figured out exactly how I'll do it.
  27. > Doom's way to do it must be very approximate, because sometimes, when you
  28. > move along a wall, it seems like you bump on lines or columns, see what I
  29.  
  30. Yes, I know.
  31.  
  32. > mean? You move away, then closer, then away. It's not very smooth. You must
  33. > have a table telling you all the objects that are contained in each square
  34. > of a map (independant from ssectors). This table's initial state is in the
  35.  
  36. What square? There are no squares in a DOOM map AFAIK. You can easily get
  37. hold of all the lines enclosing a sector, though. Then you only have to
  38. check if you cross any of them. If you don't there's no problem, if you do
  39. a further check will have to be done to see if the line you crossed was
  40. actually a wall.
  41. Not very difficult in principle, but the checks against the lines could take
  42. quite a bit of time. Do you remember reading anything about the sector
  43. breakdown in DOOM? Are they always convex perhaps?
  44.  
  45. > The easiest way must be to check all the walls that are in the same
  46. > square as you. The same algo will rule the behaviour of monsters,
  47. > projectiles, etc.
  48.  
  49. Yes, apart from the 'squares' that's how I envision it.
  50.  
  51. > >different colours depending on when they're clipped. The map rotates when
  52. > >you turn around so that 'up' is always in front of you. Looks really nifty!
  53. > How do you bring that to the screen?
  54.  
  55. Well, the screen is always drawn in a chunky buffer at first and then
  56. converted for the screen, so I simply wrote a fixed point line routine
  57. that writes into the buffer. I didn't bother optimizing the routine since
  58. it's fast enough not to matter at the moment.
  59.  
  60. > >I'll try to get a screen dump of a really bad case for you.
  61. > Yes, please do so. My mailer supports MIME.
  62.  
  63. I'll post it uuencoded to the list.
  64.  
  65.  
  66. -- 
  67.   Chalmers University   | Why are these |  e-mail:   d8klojo@dtek.chalmers.se
  68.      of Technology      |  .signatures  |            rand@cd.chalmers.se
  69.                         | so hard to do |  www/ftp:  rand.thn.htu.se
  70.    Gothenburg, Sweden   |     well?     |            (MGIFv5 and QLem)
  71.  
  72.